PD ROM 1

home *** CD-ROM | disk | FTP | other *** search

/ PD ROM 1 / PD ROM Volume I - Macintosh Software from BMUG (1988).iso / Electronic Messages / Delphi Digests / Delphi Vol. 2 / Delphi 2.35 < prev next >

Wrap

Text File | 1986-08-13 | 29.7 KB | 834 lines | [TEXT/ttxt]

del Message 1429222 has been deleted. Message: 1430005, 803 lines Posted: 1:18pm EDT, Sat Aug 9/86, imported: 4:06am EDT, Sun Aug 10/86 Subject: Delphi Mac Digest V2 #35 To: Peter_Johnston@UQV-MTS, PC Macintosh, MacTechnics User Group, John Dorsey, Alex_Ranous@UB-MTS, Abraham Vanderspek From: SHULMAN@RED.RUTGERS.EDU Delphi Mac Digest Saturday, 9 August 1986 Volume 2 : Issue 35 Today's Topics: RE: List Manager LDEF (Re: Msg 491) RE: List Manager LDEF (Re: Msg 493) RE: List Manager LDEF (Re: Msg 497) RE: List Manager LDEF (Re: Msg 490) Resource forks in text documents RE: Resource forks in text documents (Re: Msg 494) RE: Resource forks in text documents (Re: Msg 494) RE: zoom box zooming (Re: Msg 481) RE: zoom box zooming (Re: Msg 496) Undo RE: Undo RE: system dialogs (Re: Msg 488) RE: system dialogs (Re: Msg 488) RE: system dialogs (Re: Msg 488) C ambiguity? RE: C ambiguity? (Re: Msg 504) RE: C ambiguity? (Re: Msg 506) RE: C ambiguity? (Re: Msg 513) RE: C ambiguity? (Re: Msg 520) switcher bug? RE: switcher bug? (Re: Msg 505) editor features RE: editor features (Re: Msg 514) RE: editor features (Re: Msg 515) RE: editor features (Re: Msg 521) RE: editor features (Re: Msg 521) RE: editor features (Re: Msg 522) RE: Ruggedized MacIntosh LightSpeed C vs. TML Pascal RE: LightSpeed C vs. TML Pascal (Re: Msg 11394) RE: Best 'C'? (Re: Msg 11385) RE: Best 'C'? (Re: Msg 11385) RE: Best 'C'? (Re: Msg 11400) RE: Best 'C'? (Re: Msg 11400) RE: Best 'C'? (Re: Msg 11449) RE: Best 'C'? (Re: Msg 11455) RE: Best 'C'? (Re: Msg 11461) RE: Best 'C'? (Re: Msg 11449) RE: LW Cartridges RE: LW Cartridges RE: Cricket Draw (Re: Msg 11249) packet radio RE: 9600 baud terminal emulator (Re: Msg 11381) RE: Cricket Draw (Re: Msg 11450) RE: Public Domain Software Request Very Weird Problem ----------------------------------------------------------------------- From: MARSHG (493) Subject: RE: List Manager LDEF (Re: Msg 491) Date: 6-AUG-00:09: Developers' Corner There's a "bug" in the list manager that, depending on your development -system, may or may not bite you. In the original list manager distribution, selflags was defined as a byte. In the new distribution, it's a signed byte. With structure alignment, the list manager expects the pad byte that's thrown in to be sign extended. Since the lOnlyOne bit is the high bit in selflags, the pad byte must be 1 filled (set to -1) for lOnlyOne to really work. If you do that, you will only be able to select one cell. WARNING- you can force more than one cell to be selected with lsetselect even with onlyone set. Hope it helps... Marsh Gosnell ------------------------------ From: DWB (497) Subject: RE: List Manager LDEF (Re: Msg 493) Date: 6-AUG-01:55: Developers' Corner Are you sure about this? My copy of the List Manager documentation lists selFlags as the first of two bytes, the other being the Boolean "Active" If that is really the case, then there shouldn't be any pad bytes generated. The analogous situation might, however, exist with the high order bit of listFlags, but since the high order bit isn't defined to have any meaning that hardly matters. David ------------------------------ From: MARSHG (503) Subject: RE: List Manager LDEF (Re: Msg 497) Date: 6-AUG-20:51: Developers' Corner selflags is supposed to be a "signed byte". Setting lOnlyOne is supposed to sign extend the pad byte. As a regular "byte", it doesn't. Believe me on -this one, I got the answer from tech support. Marsh ------------------------------ From: LOGICHACK (525) Subject: RE: List Manager LDEF (Re: Msg 490) Date: 8-AUG-03:14: Developers' Corner I don't know about the scaling but the cache definitely uses the pram copy in the globals area. I did some stuff with it months ago because I was writing a game that used both screens so I did this nasty: I save the screen memory someplae and then turned the cache off. When I exit, I restore the memory and turned the cache back on. Talk about a hack!! Did anybody ever notice that the standard LDEF will hide its scroll bars when its window is deactived? This is per IM but funny thing is Finder breaks the rule and I like the empty scrollbar better. I worked around it but its pretty ugly. If anyone has comments or a clean solution, please let the list programming world know. Paul :) ------------------------------ From: MARSHG (494) Subject: Resource forks in text documents Date: 6-AUG-00:13: Programming Techniques I'm working on a project where I'll need to add a resource fork (and a few resources) to text documents that ordinarily don't have a resource fork. Does anybody know of any applications that will get into trouble if they find a resource fork? Do I have to worry about the application throwing the resource fork away on me? Thanks in advance. Marsh ------------------------------ From: ASMCOR (502) Subject: RE: Resource forks in text documents (Re: Msg 494) Date: 6-AUG-03:40: Programming Techniques Marsh - I have done this without problem in the past -- I believe MDS Edit does it, in fact, storing info on fonts etc. Unless the file is deleted, I don't think the resource fork would be removed, although I suppose some application might change or overwrite the resources. I'm interested to see what others have to say about this, too. Jan ------------------------------ From: DDUNHAM (516) Subject: RE: Resource forks in text documents (Re: Msg 494) Date: 7-AUG-21:53: Programming Techniques I'm pretty sure that QUED throws out your resource fork. miniWRITER installs its own resources; I've never seen any program have -trouble because they're there. ------------------------------ From: DWB (496) Subject: RE: zoom box zooming (Re: Msg 481) Date: 6-AUG-01:39: Programming Techniques Personally, if they're going to put in zoomrects they really ought to have a way of turning them off. If you remember back a ways, there was a lot of discussion about how to turn zoomrects off in Finder 1.1g. I believe that there is currently a flag in the LAYO resource which controls whether or not it is done. Problem is that doing it takes time (albeit marginal) which could be better spent doing something else. David ------------------------------ From: DDUNHAM (518) Subject: RE: zoom box zooming (Re: Msg 496) Date: 7-AUG-21:54: Programming Techniques I can't imagine why anyone would want to turn off zoomrects. I remember selecting 8 folders and choosing Open back in Finder 1.0, just to see all the zooming. ------------------------------ From: DDUNHAM (519) Subject: Undo Date: 7-AUG-21:54: Programming Techniques I will be going to MacWorld Expo, Boston. See you there. My philosophy of Undo: All Mac programs have it. Or else they're not really Mac programs. Or do you want me to tell you how to do it? I'm to embarrassed by the way I -do it now, I've been too lazy to do it right (partly because the Note Pad DA -tries to do it right and has a bug). ------------------------------ From: LOGICHACK (523) Subject: RE: Undo Date: 8-AUG-03:04: Programming Techniques Ric: What really gets me is that they could have put in an Undo item at no cost to the program. I think having a dimmed undo item is MUCH better than not having any. Did they think people were not going to notice this deficiency just by -no having the menu there? Where I come from, this is called lame. L-A-M-E! Paul :) ------------------------------ From: ASMCOR (501) Subject: RE: system dialogs (Re: Msg 488) Date: 6-AUG-03:36: Programming Techniques You need to know the item number of the button, then use HiliteControl to change it's appearance. You can get a handle to the control with GetDItem by passing it the item number, dialog pointer, etc. Only problem is that with PrJobDialog the package usually handles putting up the dialog itself and you never get to see it. So, you'll have to pre-load the dialog, change it, and then call PrJobDialog and see what happens. It may be that your changes will be over-ridden, I haven't tried this. That's what I'd try first, though. Anyone else got a clever idea? Jan ------------------------------ From: DDUNHAM (510) Subject: RE: system dialogs (Re: Msg 488) Date: 7-AUG-03:27: Programming Techniques You'll need to call PrDlgMain(print_rec,MyJobInit) instead of PrJobDialog() where pascal TPPrDlg MyJobInit(); Lew Rollins gave me the details; apparently these are undocumented features Apple is writing a Tech Note about. Aztec C does include PrDlgMain() in its library, but not TPPrDlg. (that's pascal TPPrDlg MyJobInit() with a space) ------------------------------ From: LOFTUSBECKER (511) Subject: RE: system dialogs (Re: Msg 488) Date: 7-AUG-06:49: Programming Techniques Did you try using ResEd on the dialog to disable the button? Or do you mean you want to do that from a working program? (Get the resource, use HiliteControl, I think, to disable it, make it unpurgeable while you use it, and go). - Lofty ------------------------------ From: JOSEF (504) Subject: C ambiguity? Date: 6-AUG-21:27: Programming Techniques I managed to generate an assignment expression the other day that behaves differently depending on which compiler I'm using. I realize this is farily easy to do in C, but I'm wondering whether one or possibly both are correct. Here is the problem: in the expression *p++ = *p is the assignment supposed to take place before the pointer is incremented, or is this left up to the compiler? The results will of course be different for the two cases. I carefully perused Harbison & Steele but could find no unambiguous answer. My cross-compiler at work does it one way(assignment first) and LightSpeedC the other(increment first). I suspect this decision is left up to the compiler (which means I'm being what Harbison & Steele refer to as a "too-clever programmer"). ------------------------------ From: RANDOM (506) Subject: RE: C ambiguity? (Re: Msg 504) Date: 6-AUG-22:31: Programming Techniques The assignment is done to *p, not p++, but the ambiguous part is the right side; is the value of *p taken before or after p is incremented? K&R explicitly mention the fact that ambiguous expressions like this are possible in C. Yes, it is left up to the compiler, and therefore expressions like this must not be used. I wonder if the ANSI standard is going to eliminate these kinds of expressions (by establishing an order of evaluation or something like this). ------------------------------ From: JOSEF (513) Subject: RE: C ambiguity? (Re: Msg 506) Date: 7-AUG-21:45: Programming Techniques After carefully rereaing the chapter on expressions in H&S, I decided that the correct sequence would be increment, then assignment. This means that the cross compiler I have on our 11/70 blew it again! I say again cause we have had numerous little obnoxious problems like this. Just last week I discovered the damn thing won't let you declare anything unsigned long! ------------------------------ From: PEABO (520) Subject: RE: C ambiguity? (Re: Msg 513) Date: 8-AUG-00:57: Programming Techniques Unsigned long is not in K&R. Many modern C compilers support unsigned as a modifier for any integer type, but the original unsigned is a kind of integer, not a modifier. K&R says that using ++ or -- in expressions that involve more than one -instance of the lvalue being ++'d or --'d is non-portable. Therefore, it is not surprising that you would get indeterminate results. Too bad your compiler doesn't diagnose it, but if you have lint available, you would probably find that flagged as bad C code. peter ------------------------------ From: JOSEF (532) Subject: RE: C ambiguity? (Re: Msg 520) Date: 8-AUG-21:07: Programming Techniques Sure enuf--Lint even flagged it twice! However, based on my interpretation of Harbison & Steele's chapter on expressions, I still believe that the correct order of evaluation is increment first, then assignment. Joe ------------------------------ From: JOSEF (505) Subject: switcher bug? Date: 6-AUG-21:28: Programming Techniques I was using LightSpeedC under Switcher 5.0B3 today when I got an "Application Terminated due to System Error" message. I had allocated 512K to LSC, and was just in the process of exiting from the application that I was running. I am presuming that this is a Switcher bug. Anybody got any other thoughts on the matter? Joe ------------------------------ From: PEABO (508) Subject: RE: switcher bug? (Re: Msg 505) Date: 6-AUG-23:55: Programming Techniques According to MER, who just answered that question for me, the solution is to use the COnfigure and Install menu ans specify Permanent when configuring a slot for switcher. At her advice, I used 512K as the size of the slot, and it works just fine. peter ------------------------------ From: JOSEF (514) Subject: editor features Date: 7-AUG-21:46: Tools for Developers I discovered a rather nifty feature in the LightSpeedC editor today that I haven't noticed in any of the other editors (not even QUED!): Triple clicking on any line will select the entire line--much easier than dragging down exactly one line in the left margin. I have also noticed that double clicking on a word in QUED also selects the space following that word, which is probably the right thing to do in most cases. Aren't editors wonderful!! Speaking of QUED, does anyone know what's different in 1.4 and also what their upgrade policy is? (I still have 1.3.) Joe ------------------------------ From: DDUNHAM (515) Subject: RE: editor features (Re: Msg 514) Date: 7-AUG-21:53: Tools for Developers Triple clicking could be nice; I don't use anything that supports it. QUED is WRONG about selecting the space following a word! The most common editing operation is to rephrase something. To do this, you change one word for another. Double-click the word to change, type the new one. Simple in MacWrite or miniWRITER. But in QUED, you need to pay attention to the context. If the word precedes punctuation, your job is over. If it doesn't, you'll have to insert the space. It's especially bad in QUED because you're likely to have inline comments preceded by tabs. If you select the last word before the comment, you'll get all the tabs, too, and have to re-enter them. A real pain. The only time one could make a case for selecting the space is if you delete a lot. It isn't relevant in QUED, but check the discussion in the User -Interface chapter of IM on intelligent Cut & Paste. ------------------------------ From: PEABO (521) Subject: RE: editor features (Re: Msg 515) Date: 8-AUG-01:05: Tools for Developers Doesn't MS-WORD select the space after the word on a double-click? It's been -a little while since I did any major editing in WORD, so I have forgotten, but -it is a pain to recreate the space after. peter ------------------------------ From: CHUQ (522) Subject: RE: editor features (Re: Msg 521) Date: 8-AUG-01:59: Tools for Developers Yes, WORD does select the space on double click, if there is no competing punctuation to stop it. This makes perfect sense in a word processor, and it keeps me from going insane when I'm trying to write. It'd drive me buggy if I was programming, though. Fortunately, I don't use WORD to do programs. chuq ------------------------------ From: DDUNHAM (537) Subject: RE: editor features (Re: Msg 521) Date: 9-AUG-00:12: Tools for Developers If so, yet another reason I don't use Word. PageMaker also does it, and it really annoys me (luckily I don't do a lot of text editing in PageMaker [I -have other things I want to do, too :-)]). ------------------------------ From: DDUNHAM (538) Subject: RE: editor features (Re: Msg 522) Date: 9-AUG-00:12: Tools for Developers So you delete more than you retype? Getting the space drives me up the wall equally in PageMaker and QUED. Especially since two of the programs I use most are Acta and miniWRITER, which use TextEdit, which does not select whitespace. I think this (the fact that the ROM doesn't) is the single most important reason why Word et al are _wrong_. ------------------------------ From: MACINTOUCH (11427) Subject: RE: Ruggedized MacIntosh Date: 8-AUG-09:53: Network Digests To:Peggy_B._Thomas.OsbuSouth"@Xerox.COM Subject: Ruggedized MacIntosh There was a re-packaged Macintosh sold by a company called "Colby" some time ago. I don't know if it's still being sold, but it might be a more rugged Mac than Apple's. There is also a discussion here on Delphi about military "Tempest" Macs. Ric ------------------------------ From: HALL (11394) Subject: LightSpeed C vs. TML Pascal Date: 8-AUG-00:24: Programming I've been considering buying a development system, and the choice is between LightSpeed C and TML Pascal (version 2.0, of course). The question is, which -is best overall? How do they compare in ease of use, development time, code efficiency, (Well, you get the idea).... Brian ------------------------------ From: PEABO (11396) Subject: RE: LightSpeed C vs. TML Pascal (Re: Msg 11394) Date: 8-AUG-00:45: Programming I'd take a look at Lightspeed Pascal. (That's PASCAL, not C). Usually people choose their langauge before their development system. If you don't care whether you are using C or Pascal, you probably haven't used them enough to develop a preference yet. (My opinion.) So rather than compare Lightspeed C vs. TML Pascal, I would think you'd want to compare Lightspeed Pascal vs. TML Pascal, or Lightspeed C vs. some other C compiler, after figuring out which langauge you feel best with. peter ------------------------------ From: PEABO (11395) Subject: RE: Best 'C'? (Re: Msg 11385) Date: 8-AUG-00:40: Programming Quickest and easiest for development: LightspeedC wins this one hands down. Most powerful? Well, LightspeedC is not bad, but there are other excellent C compilers, including MANX, Megamax, and Consulair (though people are opinionated about all of these). A rising star of the horizon is the Apple Macintosh Programmer's Workshop (MPW) which will be available soon and which uses Greenhills C. We don't yet have a definitive answer on how good the code is coming out of the MPW C. peter ------------------------------ From: CHUQ (11400) Subject: RE: Best 'C'? (Re: Msg 11385) Date: 8-AUG-01:52: Programming I bought Mac C 1.0 centuries ago. I upgraded it to 1.5, then to 4.0. I loved it. If you want to do it, Mac C can do it for you. Last week, I threw it off my disks and bought LightSpeed C. Why? I'm in lust. Mac C is a workhorse. It makes few assumptions, and does the job real nice. It is expensive as hell. HFS upgrade would have cost me about half as much as buying LightSpeed C cost, and Consulair seems to upgrade about three times a year. That gets expensive... Also, Mac C is NOT INTEGRATED. You load the editor. You edit. You save. You transfer to the C compiler. You compile. Maybe you transfer to the linker and link. You transfer to the program. It bombs. You start the editor. Iterate infinitely. Starting and exiting programs, even with transfer menus that skip the finder, is slow, pronounced mindbugging. Exec sucks. Even MDS make doesn't really help like it should. If all you -want is a Unix style environment that runs likka dog, Mac C is fine). LightSpeed, you boot the program. You open files, edit them. You hit command- m. It makes everything you changed. It remembers which include files go with which programs, and remake everything you need. You hit command-r. It links and transfers, testing the program. When you are done, you're back in LSC. The compiler is FAST. I mean, we're talking blink and you miss it. The linking is pretty much non-existant, although I'm hacking my way through a port of Hack from Unix and with something like 25,000+ lines of code in 30 some files, even LSC slows down. Imagine that in Mac C, though. For all this wonderfulness, you DO give up some things. You can't add random utilities. You can't choose your own editor (no big deal, I vi at work and I use Mac Word the rest of the time, so the editor doesn't bother me). It doesn't have HFS support yet officially, but I guess it is around here somewhere as a project. You also pay $130 instead of $400 for the silly thing. It isn't the compiler with the most brawn, but it is the single most -productive thing to hit the Mac market to date. I can hack things together so much -faster it isn't possible to explain it in ways that don't sound like marketing hype. I Like LSC, if that weren't obvious. About Apple's MPW, two things that I'm probably not supposed to know, from people beating on it. The code generation for the C compiler is supposed to be astounding -- Greenhills is a first class compiler house, from personal experience on big machines. Second, the sucker is aimed at professional developers, and will have every bell and whistle tyou could imagine, and then some. You'll pay for it, though -- Mac C may well be a down payment for MPW when they are through. Some people I know who have been working with MPW say it will blow away everything you've ever seen, including LSC -- they should know, they wrote a best selling C book for the Mac. If you're willing to put out the bucks, wait for MPW, coming this fall, last I heard. If not, buy LightSpeed, and hope they bring out their own object interface one of these minutes, or grab a package like Transkel. Object Pascal is going to make programming the Mac fun again, at least for Pascal programmers. chuq ------------------------------ From: PEABO (11429) Subject: RE: Best 'C'? (Re: Msg 11400) Date: 8-AUG-10:05: Programming Unless MPW C bankrupts me, I am hoping to get the best of both worlds by using LSC as a fast development tool, and then using MPW C for the "last compile" <grinning>. It has been a myth of choice for computer programmers for centuries that the way to go is a fast compiler for development and a heavy duty optimizer for production ... peter ------------------------------ From: MCOHEN (11449) Subject: RE: Best 'C'? (Re: Msg 11400) Date: 8-AUG-18:48: Programming I'm also using Consulair C now (currently V4.5) and I've been thinking about switching to Lightspeed C *BUT* it has one fatal flaw (at least as far as I'm concerned): you can't use inline assembler or integrate assembler modules easily (I've heard their RelConvert program chokes on Mac C format REL files). I'm currently working with a MIDI driver and lots of low-level stuff which can't be done easily in C. Also, I just bought MacExpress in Consulair C format. Does Lightspeed intend to support assembly language in the future? If they do, I will switch. - Mike ------------------------------ From: PEABO (11455) Subject: RE: Best 'C'? (Re: Msg 11449) Date: 8-AUG-20:06: Programming There is a rumor floating around about a September upgrade that includes assembly langauge. ALSO, a rumor floating around about an enhanced TMON with hooks into several popular compilers (to get info about the symbolic names of procedure locals) due Real Soon Now. We'll keep an eye out this week at the show for such goodies! peter ------------------------------ From: VINDICATOR (11461) Subject: RE: Best 'C'? (Re: Msg 11455) Date: 8-AUG-21:01: Programming I love Lightspeed, but before that I used Megamax a lot, and I still think it's an excellent package. The new upgrade to 3.0 supports HFS, etc., so if you don't want to buy Lightspeed (which you should) and if you want assembly support, I'd try Megamax. It's also cheaper than Mac C, but then, what isn't? ------------------------------ From: JEFFS (11469) Subject: RE: Best 'C'? (Re: Msg 11461) Date: 8-AUG-21:46: Programming But have you *seen* the upgrade? I haven't and I sent in my disks way back in March! Jeff ------------------------------ From: JOSEF (11486) Subject: RE: Best 'C'? (Re: Msg 11449) Date: 9-AUG-01:52: Programming I've used LSC's RelConvert to convert Mac C .rel files with no problems whatsoever. Would be interested in knowing what kind of problems you have -heard about. Joe ------------------------------ From: MOUSEKETEER (11459) Subject: RE: LW Cartridges Date: 8-AUG-20:28: Programming I hadn't heard of any carts being filled to less than capacity...and not getting at least 2000 sheets through would be very strange, I think (unless the sheets have a tremendous amount of black in them, which could eat toner at a very advanced rate....try black paper and do the drawing in white...grin). Maybe someone who has been through more carts than I has other experiences? Alf NOTE NOTE NOTE: The new Macworld has a letter from someone discussing how to arrange your sheets from WORD in the Laserwriter to print on both sides. FROM ASKING QUESTIONS ABOUT, THIS IS BAD MOJO! The Canon engine is rated at around a 10% duty cycle for double-sided copies, but no-problem printing requires more like 5%, or preferably none at all. If you need stuff done double-sided, take it to a copy shop and use their Kodak. ------------------------------ From: MACINTOUCH (11499) Subject: RE: LW Cartridges Date: 9-AUG-08:28: Programming Hey, what's the scoop?! I've been running double-sided almost continually to save money on paper. I had real minor thoughts about problems, but haven't encountered any. What _exactly_ happens in this mode that doesn't in the other? (No, Rick, we _can't_ buy a copier!) Ric ------------------------------ From: MACMAG (11450) Subject: RE: Cricket Draw (Re: Msg 11249) Date: 8-AUG-19:33: Business Mac Although I haven't seen the program, someone here bought it and says it's the best "plotter" program you can buy today. (aka. Cricket Draw) RICH. ------------------------------ From: OPPENHEIM (11457) Subject: packet radio Date: 8-AUG-20:17: Hardware & Peripherals Since the Zilog SCC chip is used in some amateur packet controllers for SDLC communications, has anyone done anything to harness the Mac for this task? Another coup for the Mac, with all the drones slaving to make the PC do the work in software. ------------------------------ From: YVES (11466) Subject: RE: 9600 baud terminal emulator (Re: Msg 11381) Date: 8-AUG-21:18: Telecommunicating Yes, you're right: the big screens just have a new Bitmap definition (address, rowbytes and rectangle). Unfortunately I had to use some very tricky programming to become that fast and that meant assuming the size of the screen. However, when Apple comes out with a new size of screen, I will modify the programs to be compatible with both (people with MegaScreens STILL have the standard screen if they don't boot the special disk). This until the Mac becomes fast enough to handle 19200 baud by itself (I'm thinking 68020). At that time, any terminal program will do... -- Yves ------------------------------ From: RICKLEPAGE (11472) Subject: RE: Cricket Draw (Re: Msg 11450) Date: 8-AUG-22:37: Business Mac this is an entirely different program -- Cricket Graph is the graphing -program. Cricket Draw wont even be shown officially till the expo and won't be sold -till at least the end of the year. Rick ------------------------------ From: DDUNHAM (11479) Subject: RE: Public Domain Software Request Date: 9-AUG-00:05: Network Digests >From: binde@topaz.rutgers.edu (Beth Binde) >Subject: Public Domain Software Request miniWRITER is not a public domain word processor (I don't know of any -- MacWrite is NOT), but it is a shareware text processor. It is the only such desk accessory which supports Undo. You can contact us about a site license ( the shareware fee is normally $12) : Maitreya Design POB 1480 Goleta, CA 93118 805/968-7578 (do NOT call before noon Pacific) Good luck trying to find free software...I think you're going to need it. ------------------------------ From: LOFTUSBECKER (542) Subject: Very Weird Problem Date: 9-AUG-02:42: Programming Techniques All right, this is a real mystery to me. Anyone have any ideas? On my Mac (512K with new ROMs), I found out, moving the hex number $28EFFFF to register A0 caused an immediate mouse freeze. Some experimentation helped me determine (1) this doesn't happen when the same number is moved to register D0 or A1 (I haven't tried all registers); (2) it happens whether the number is loaded directly into A0, or whether it is moved there from D0 or A1; and (3) in fact the critical bit seems to be Bit 23 ($800000): just moving $800000 into register A0 will cause the freeze. I've done almost all my experimenting with TMON (but not all, a little bit with the minidebugger in ROM). The mouse freeze happens 100% of the time in TMON, and I have duplicated it with the mini- debugger (entering 207C 028E FFFF A9F4 into memory locations following 0000 and then setting the program counter to 0 and telling the little debugger to G will do it). IS THIS COMMON TO ALL MACS? Or is there something strange, very strange, about mine? Can anyone replicate the problem? Does anyone have any idea what the hell is going on? Is it a bug in TMON? (Very puzzled) -- Lofty. ------------------------------ End of Delphi Mac Digest ************************ ------- Next, history, delete, reply, help, etc.? @